An embodiment relates generally to vehicle controller area network systems.
Controller-area network (CAN) is a vehicle bus standard intended to allow electronic control units (ECUs) and other devices to communicate with one another without a central or host computer. Vehicle systems and subsystems have numerous ECUs that control actuators or receive data from sensing devices. Many subsystems that the ECUs control are independent subsystems having no communication with another subsystem, while other subsystems communicate and share data (e.g., engine control unit and the electronic braking control unit).
The CAN system is an asynchronous broadcast serial bus which allows messages to be communicated serially. Therefore, messages between ECUs when transmitted are not necessarily transmitted immediately over the CAN bus when a message is generated. If the CAN bus is free, the message is instantly transmitted. If more than one message is transmitted, the more dominant message is transmitted. This is known as an arbitration process. A CAN message with a highest priority will dominate the arbitration and a message transmitting at the lower priority will sense this and wait. This is achieved through a binary bit system using dominant bits and recessive bits. A CAN message includes an ID that identifies a message-type or sender. The ID consists of a predetermined number of data bytes. For example, an ID may consist of 8 data bytes utilizing “0”s and “1”s. Dominant bits are a logical “0” and recessive bits are a logical “1”. Dominant bits receive the higher priority than do the recessive bits. During an arbitration process, the more dominant ID having the lower bit value will win arbitration and have priority.
Due to the delay in transmitting information in the recessive bits, data sharing and integration of data between two ECUs of different CAN buses in a multi-CAN bus architecture may result in out of synchronized data being integrated together if their clocks are not synchronized. That is, to integrate data, a processor must know that it is using data that is collected by the various sensors at substantially a same instant of time. ECUs utilize their local clocks to time-stamp data, and if the local clocks are not synchronized, then a mismatch of timed data may occur during data integration process. A vehicle could use an internal clock in attempts to synchronize the time of all the ECU's by sending out a clock signal; however, due to the asynchronous nature of the CAN system and delays that result in transmitting messages across different CAN buses, a message containing a clock signal may be delayed as well in getting to the ECU's which would result in the local clocks of the ECUs of different CAN buses being unsynchronized. In a vehicle-to-vehicle (V2V) case, it may also be relevant for vehicles to use sensor data from other vehicles to perform onboard sensor fusion and perform appropriate actuation and control. The sensors connected to CAN bus in remote vehicles which are transmitted using V2V messages need improved accuracy than what is available with using just the V2V time synchronization mechanism that is typically based on GPS.